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Abstract —In the recent years, WiFi standard has been used to 
develop different kind of wireless networks due to its flexibility 
and the availability of cheap off the shelf hardware. Even if 
the standard itself lacks mobility support, it has been used in 
networks with mobile nodes. When mobility is involved, a fast 
handoff is of paramount importance, especially with multimedia 
applications. The current IEEE 802.11 standard does not provide 
any specification about how the handoff should take place. 

In this paper we propose a handoff scheme optimized for 
networks providing wireless connection to mass transit vehicles. 
The structure of the procedure is redesigned to minimize delay as 
well as assure reliability. A reliable handoff triggering mechanism 
is also designed exploiting the results obtained from a set of 
preliminary outdoor experiments. 

The proposed scheme was implemented and deployed in an 
experimental testbed, and several indoor tests were run in order 
to demonstrate its reliability and efficiency. 

I. Introduction 

The use of 802.11 technology has been growing expo¬ 
nentially in the last years due to the low cost of hardware 
and the lack of need for licensed bands. One of its last 
application is in the context of providing Internet connection 
to vehicles of a mass transportation system. The main goal 
is to bring Internet connection to the passengers, in addition 
to deploying additional services which need connectivity, e.g. 
video surveillance, monitoring or ticketing. Since originally 
the WiFi standard was not designed to provide connectivity 
to mobile nodes, the lack of several features for mobility 
management raises several issues which must be taken into 
account in such deployments. 

In particular, WiFi does not cope with the problem of 
handoff which, however, is of paramount importance for 
mobile users, since it takes care of transferring the established 
connection from one access point to another over the time. 
As a matter of facts, the handoff support in IEEE 802.11 
standard 0 is insufficient: a node switches the connection 
from one AP to another only after the signal strength of the 
actual connection is so weak that the association is lost. This 
procedure can cause a significant disruption of the service 
which is unfeasible in case of multimedia applications. 

Nevertheless, actual mass transit networks have been de¬ 
ployed using 802.11 standards, i.e. North County Transit 
District a and Seoul Metropolitan Rapid Transit 0. Each 
solution copes with the issues related to mobility, with ad hoc 
solutions deployed by the manufacturers of the devices, e.g. 


0. However the proposed solutions are proprietary and they 
do not assure the compatibility among products of different 
brands. 

In 2008, the IEEE working group “k” has standardized 
a new amendment to the IEEE 802.11 standard in order to 
add fast handoff support 0- However this amendment mainly 
covers the issues related to security and interoperability and 
it does not define any guidelines on how the handoff itself 
should be realized. 

In this work we present a handoff procedure specifically 
designed for networks providing connectivity to mass transit 
vehicles. We exploit the structure of the network to design an 
optimized handoff procedure which minimizes the additional 
delay. In particular, a set of preliminary experiments has been 
run to characterize the channel quality over time for a mobile 
node connecting to multiple APs. Upon the results of the 
preliminary measurements, a triggering procedure is designed 
to assure the reliability of the connection. The proposal is 
implemented on our testbed and its performance is assessed 
through a set of experiments. 

The rest of the article is organized as follows. In Section HT1 
we illustrate the architecture of our testbed. In Section [Till we 
present the preliminary measurements on the channel quality. 
In Section |IV| we illustrate our proposal, while in Section fVl the 
results of the performance evaluation are presented. Finally, in 
Section ED we draw the conclusions. 

II. Testbed architecture 

A. Architecture 

The WMN testbed we developed is composed by five wire¬ 
less mesh devices provided by Fluidmesh Networks ifTOt Each 
node is an embedded system used for algorithm prototyping 
consisting of an x86-compatible, Pentium class CPU, 128 MB 
of RAM and two 802.11 a/b/g network cards. The hardware 
device behind each wireless adapter is an Atheros AR5212, 
one of the most popular chipset commercially available. On the 
software side, we have chosen to base our architecture upon 
the OpenWrt operating system j TO . a Linux-based distribution 
widely adopted for embedded devices. In order to add mesh 
functionalities to the system, we decided to leverage on an 
existing implementation. Roofnet m is a wireless mesh 
network developed by MIT at Cambridge, Massachusetts, with 
the aim to test new proposals such as routing protocols and rate 


adaptation algorithms aimed to improve the efficiency of the 
network itself. Its modular and open source implementation 
has made it one of the most studied kind of WMNs. The 
core of the Roofnet implementation is the Click Modular 
Router , a software program running at the kernel level which is 
responsible for overriding the normal network stack provided 
by the operating system. The behavior of a network node 
can be easily re-defined and adjusted using Click’s object 
model, where packets flow along a collection of interconnected 
functional elements forming a graph, each of them performing 
a basic operation such as header manipulation, classification, 
scheduling and so on. Roofnet itself is therefore composed by 
a set of Click elements, i.e. SRCR , the routing module. SRCR 
(SouRCe Routing) is an ad hoc source-based routing algorithm 
derived from DSR and it is responsible for selecting the path 
of each flow in the network minimizing, at the same time, 
the end-to-end transmission time quantified by the Estimated 
Transmission Time (ETT) metric. 

Building on this well-assessed scenario, we have developed 
a number of enhancements to extend the basic Roofnet system 
in order to increase the dependability level of the overall 
network. Specifically, our primary goal was to reduce the 
disruption time of the packet delivery service, which can be 
particularly relevant in application scenarios such as video 
surveillance, site monitoring and remote control. By default, 
the WMN routing protocol is quite conservative in terms of 
reactiveness to drastic variations of the link quality or changes 
in the network topology, e.g., as a consequence of a node fault. 
This is a classic behavior in WMNs, as transmission errors 
occur frequently due to the intrinsic nature of the medium, 
which marks a difference from wired networks, where perma¬ 
nent link failures can be easily detected and several mechanism 
exists to compensate the fault at the time scale of a few 
tenths of milliseconds. SRCR makes no exception to the 
rule and in its default setup we measured a routes update 
time in the order of the minute. While it is possible to 
tweak the configuration of the protocol parameters to speed 
up the convergence of the routing process, this approach is 
generally not recommended to avoid excessive route flapping 
which leads to unstable performance. Therefore the existing 
architecture should be extended with additional mechanisms 
which provide the desired resilience improvements without 
disrupting the routing stability and performance. 

Figure [I] illustrates the functional blocks which compose our 
system and their interactions. As stated before, the OpenWRT 
operating system and the Roofnet software are the base 
architecture that provides the foundations to our work. In order 
to implement the required resilience enhancement that is the 
objective of our contribution, we have developed a series of 
modules which will be examined in detail in the rest of this 
section. 

B. MPLS forwarding 

The MPLS subsystem implements a fully functional label¬ 
switching packet forwarding mechanism operating at an in¬ 
termediate level between the MAC and the network layers, 



Fig. 1. Mesh router system architecture. 
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Fig. 2. MPLS shim header structure. 

for which it is often referred to as a layer 2.5 mechanism. In 
our WMN architecture it represents a strategic element which 
provides the foundations to build advanced services such as 
resiliency enhancements based on fast-rerouting techniques, 
traffic engineering capabilities, mobility support and so on. 
Our design follows the reference MPLS specification o and 
supports the standard shim header structure (Figure [2]), ether- 
type encapsulation and label stacking capability which should 
grant for inter-operability with other MPLS implementations. 
The implementation consists in three Click router elements 
which closely match the functional blocks described in the 
IETF RFC. Figure [3] illustrates the relationship between the 
modules and their respective data structures. The FTN (FEC- 
to-NHLFE) element matches “regular” ethernet-encapsulated 
IP packets with a set of configured Forwarding Equivalence 
Classes (FEC), i.e. instances of a packet classification scheme 
which in the current implementation is represented by the tuple 
(src_ip, src_port, dstjp, dst_port, proto). Whenever a packet 
is recognized to belong to a known FEC, a 32-bits MPLS 
shim header is added after its MAC header and then it is 
emitted from the first output; the label value stored inside 
the shim header represents an internal index (JDX ) into the 
NHLFE table, which will be described later. Non-matching 
packets are passed unmodified through the second output 
for normal processing inside the Roofnet router. The ILM 
(Incoming Label Mapping) element, instead, receives packets 
already encapsulated with one (or more) MPLS headers as 
they are being forwarded along an LSP; the top-level label 
in the stack is simply looked up in the internal table and 
replaced with the corresponding NHLFE pointer if present, 
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Fig. 3. MPLS forwarding subsystem. 

otherwise the whole packet is discarded. The NHLFE (Next- 
Hop Label Forwarding Entry) element is where the label 
switching process actually takes place: the internal label value 
assigned either by the FTN or the ILM elements is used 
to select a table entry which specifies the operation to be 
performed on the considered packet. Implemented operations 
are: PUSHing a new shim header onto the stack, POPping 
the top-level header, and SWAPping the label with a different 
value; the required parameters such as the replacement label 
value are specified in the various fields of the table. 

III. Preliminary measurements 

It is well known that the quality of a wireless channel 
varies almost unpredictably over the time, depending on a 
number of factors. In particular, the effects of fading and 
path loss influence more significantly the channel quality 
over the time if one of the nodes involved is moving. We 
decided to run some preliminary experiments to characterize 
the channel quality when mobility is considered. The goal is to 
monitor the variation of the signal quality over time, without 
the intervention of any handoff mechanism. The experience 
gathered from the results of the experiments is afterwards used 
to design the handoff scheme, and in particular the triggering 
mechanism. 

In order to have an initial insight on mobility, we prelimi¬ 
nary run some indoor tests to collect statistics in a controlled 
environment. We setup the experiments in the corridor of our 
department where the factors which can affect the results are 
known a priori. Later on, we run some outdoor scenarios to 
gather results also with a setup closer to a real scenario. In 
the latter we decided to place the experiment in a real urban 
area, installing one node on the roof of a car moving through 
the traffic. 

We used the same setup for all the preliminary tests con¬ 
ducted, the main difference among them being the location 
environment and consequently the velocity of the mobile 
node: pedestrian for indoor, i.e. in the range 3-10 Km/h, 
and vehicular for outdoor (20-50 Km/h). Each run consists 
in a mobile router moving along a pre-established path, with 


Name 

Value 

Number of fixed nodes 

3 

PHY mode 

802.11a 

Type of traffic 

Bidirectional ICMP 

Traffic rate 

6 Mbps 

Number of packets per second 

75 packets 

Routing 

Static forwarding using MPLS paths 


a number of fixed nodes placed aside the route to provide 
backbone connectivity. The distance among the fixed nodes is 
chosen in order to simulate a real handoff scenario, i.e. the two 
nodes are placed to have their coverage range only partially 
overlapping at the border. 

Table [TV] illustrates the settings. As it can be seen, the 
mobile node sends a constant-rate ICMP traffic to all the three 
fixed routers placed on the path. This probing traffic enables to 
collect statistics on both the uplink and downlink directions. 
As far as the routing is concerned, a fixed forwarding con¬ 
figuration has been setup using static LSPs on all the nodes, 
in order to maintain precise control over the routing and to 
avoid, for instance, undesired flapping of routes during the 
experiment. 

During the experiments, each router collects per-packet 
statistics at the MAC level, namely RSSI (Received Signal 
Strength Indication) and packet loss. RSSI is generically de¬ 
fined by the standard as a numerical value related to the signal 
level received by the radio antenna, but no exact relationship 
with physical power scales is given. In fact, the actual meaning 
of RSSI samples is specific to hardware implementations, i.e. 
it is defined by the manufacturer of the radio chipset interface. 
In our case, for the adopted Atheros-based cards, the RSSI is 
defined as the RSSI = SNR+96 in a scale ranging from 0 
to 70, where the SNR is the power expressed in dBm. For 
incoming packets, the reported RSSI value is sampled during 
the preamble and the PLCP header, while for transmitted 
packets it is the level at which the ACK packet has been 
received. The amount of lost packets over the time is derived 
from the transmission status report collected for each packet, 
together with the number of re-transmissions occurred before 
the successful reception of the ACK. 

The configuration is illustrated in Figure 01 three fixed nodes 
(R2, R3 and R4) are placed along a path traveled by a mobile 
node (Rl). Each radio interface is configured on the lowest 
channel of the 802.11a frequency range. The 802.11a mode is 
adopted instead of the ’g’ in order to avoid interference from 
the existing wireless networks of the department. 

Figure [5] illustrates respectively the RSSI and the packet 
loss resulting over the time. For the sake of brevity, we 
show data relative to the downlink traffic only. Each curve 
reports the results related with the traffic from one of the 
fixed routers. As already anticipated above, the packet RSSI 
is measured at the destination when the packet is received 
by the mobile node, while the packet loss information is 
collected on the transmitting node. As can be seen, as the 
mobile node moves along the path, the transmission quality 
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relative to each fixed router varies according to the distance. 
Considering one fixed router at a time, the corresponding 
RSSI curve assumes a bell shape, and the different bells are 
shifted over the time by an interval which depends both on 
the distance between the routers and the absolute speed of the 
mobile node. As a matter of fact, the RSSI perceived between 
two nodes mainly depends on the path-loss which degrades 
the signal strength proportionally to the distance. Even if the 
RSSI has a distinguishable long-term trend, it is characterized 
by local high-frequency oscillations caused by the channel 
fading. Moreover, looking at the same curves, we observe 
local down-peaks in the middle of the bell where, instead, 
the highest value is supposed to appear. We believe that this 
phenomenon is related to the very close distance between the 
devices antennae, which produces a temporary blinding effect 
on the radio interfaces. 

As far as the packet loss is concerned, we note that strong 
correlation with the RSSI level can be observed. In particular, 
when the RSSI is below 26 the packet loss can grow noticeably 
high, even in the order of 40%. This kind of simple threshold 
relationship has been reported to apply for wireless channels 
operating in low-interference environmental conditions, such 
as those experienced in rural areas and more in general in 
absence of strong RF emissions in the considered spectral 
bands. 

Eventually, looking at the results in their entirety, three 
different zones can be identified in the graph, each one 
dominated by a particular fixed router. It is straightforward 
that the handoff mechanism can exploit this peculiarity to 
maximize the overall quality for packets transmission. 

IV. Handoff 

As previously described, a classic handoff mechanism is 
composed by three phases, namely triggering, search and 
execution. The overall performance of the scheme is mostly 
determined by the efficiency of the first two phases: the 
triggering process is critical as it is responsible for preventing 
excessive degradation of channel conditions by taking handoff 
decisions at the most appropriate time, while the search phase 
causes an interruption of the network service for the time 
it takes to scan the various channels for another node to 
connect to; for conventional devices, this time usually amounts 
to several hundreds of milliseconds, which may cause a 
significant service disruption. On the other hand, the execution 
phase does not introduce a significant delay, since the channel 
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Fig. 5. RSSI and Packet loss for indoor scenario. 

switching operation is usually performed by radio interfaces in 
a few milliseconds. For this reason, we focus our attention only 
on the first two phases for our design, assuming a negligible 
delay for the execution process. 

The search phase is the one which can benefit the most from 
specific optimizations permitted by the particular scenario 
selected for our study. Since the path followed by the mobile 
node is fixed, we can assume that the complete sequence of 
nodes visited along the path is known a priori. This allows 
us to scrap the searching phase completely from our design, 
replacing it with a simple list of node addresses deduced both 
from the network and the transportation plans. During the 
course, a simple table lookup operation is required by the 
mobile router to obtain the address of the next node to connect 
to, depending on the current point of attachment to the fixed 
backbone. To provide a minimum level of flexibility in the 
system, the content of the nodes list could be periodically 
updated by a centralized server in an automatic manner: this 
would ease the maintenance process of the devices configu¬ 
ration in case of topology changes, as well as fast recovery 
from possible network failures. 

Consequently, the main effort of our contribution has been 
concentrated on the triggering phase. In order to design an 
efficient scheme, we strongly leveraged from the experience 
gained with the results of the preliminary experiments. As il¬ 
lustrated in Section [Till RSSI provides a fairly good indication 
about the quality of the channel and therefore it represents a 
primary candidate metric for our triggering decision algorithm. 
For increased reliability in presence of significant radio inter¬ 
ference, packet loss information is also considered in some 
circumstances, as it will be discussed later on. As shown in 
our preliminary analysis, raw RSSI samples are affected by 
short local transients mainly due to the highly time varying 
channel conditions caused by shadowing and fading. 

Therefore, in order to take the correct decisions based on 
























Fig. 6. Smoothed RSSI curve for indoor scenario (s=6). 

real-time signal strength monitoring, the RSSI values need to 
be pre-processed to remove high frequency components in 
the signal. To this aim, after some preliminary evaluations 
we decided to adopt an exponential weighted moving average 
(EWMA) filter, which showed to provide adequate signal 
smoothing characteristics at the price of a modest computa¬ 
tional complexity as required for an efficient implementation 
in real system. The EWMA filter is defined by the following 
formula: 

RSSI old (t ) = aRSSI curr (t) + (1 - a)RSSI old (t - 1) (1) 

where the a parameter is a real number which determines the 
strength of filtering process. Due to the inability to manipulate 
floating point values inside the Linux kernel, our EWMA 
implementation uses a slightly modified version of the formula 
where a is replaced by the expression 1 /2 s , which contains 
the integer value s, called stability shift and it can be evaluated 
without the need of floating point arithmetics. 

Figure [6] shows the same set of data displayed in Figure \5\ 
after being processed by the EWMA filter configured with a 
stability shift parameter s=6. In the resulting curves the high- 
frequency noise oscillations have been strongly attenuated, 
while the signal still closely follows the short-term trend of 
the original data. The value of the stability shift parameter can 
be optimally determined for each specific case of deployment 
of the system as a trade-off between the desired strength of 
the low-pass effect and the delay introduced by the filter. In 
particular, the higher the value of s , the cleaner and smoother 
the output signal is, but at the same time the curves will be 
shifted to the right in a proportional manner, introducing a 
delay for any subsequent handoff decisions. Consequently, 
the maximum speed allowed for the mobile node in order 
to maintain the desired level of performance will be limited 
accordingly. 

Once that a reliable metric to measure the channel quality 
was identified, a triggering algorithm has been defined to 
determine the most appropriate points in time to perform the 
handoff process basing on the current status of the RSSI levels, 
so as to minimize the packet loss. In our solution, the mobile 
node continuously monitors the signal strength received from 


the current point of attachment to the network and from the 
next node expected along the path. The decisional process 
consists in comparing the two EMWA-averaged signals against 
single hysteresis thresholds, i.e. when the value of the next 
node’s RSSI is found to be higher than the current node’s 
value by at least A dBm, the handoff is triggered. Such 
process is run by the mobile node at regular intervals, e.g. 10 
times per second; again, an acceptable compromise between 
responsiveness of the handoff and system overhead needs to 
be determined. 

In order to increase the accuracy, we decided to adopt two 
different hysteresis thresholds: one (\ G ) is applied when the 
handoff is going to take place in a region characterized by 
high RSSI values, while the other (A#) is considered in case 
of low-quality channel conditions, i.e. when significant packet 
loss is more likely to occur. In our tests we usually assumed 
A b < A g- This allows to anticipate the connection to the 
next node when the active link is in unstable conditions. 
To distinguish between the two operating regions, another 
threshold [3 is compared to the current signal level: X G is 
used in the algorithm if the RSSI is above /3, otherwise A# is 
considered. Moreover, in the latter case the handoff is triggered 
only if the packet loss experienced with the next node is 
low enough (< Pl) despite the scarce reception quality. The 
rationale behind these assumptions is to avoid delaying the 
switch from the current node too far in time in presence of bad 
channel conditions and, conversely, to prevent unnecessarily 
early handoffs when the signal quality stays good during 
the movement. The triggering procedure can be summarized 
through the following pseudo code: 
if RSSI curr > /3 then 
if RSSI next > RSSI curr + \ G then 
Do Handoff 
end if 
else 

if RSSI nex t > RSSI curr -\-XB AND PacketLoss < Pl 

then 

Do Handoff 

end if 
end if 

Packet statistics, including RSSI measurements, can ob¬ 
viously be collected only in presence of network traffic; in 
general, higher channel utilization levels translate into finer- 
grained resolution of the RSSI curves and thus better accuracy 
of the handoff process. Regular data packets transported by the 
mesh are normally processed by the monitoring subsystem, 
however some alternate mechanism must also be taken into 
account to cope with situations where no or insufficient traffic 
volumes are being exchanged in the network. In particular, 
this is very likely the case when the mobile node needs to 
get measurement data from the next node in the path, since 
it is currently communicating with the attached node and 
no assumptions can be made concerning independent packet 
transmissions made by the next node to other routers. The 
mechanism provided in our solution consists in the transmis¬ 
sion of unicast ICMP background traffic at very low rates (but 





TABLE V 

Handoff settings 


Name 

Value 

Stability Shift 

6 

p 

25 

Ag 

6 

As 

3 

Pl 

0.5 

Probing traffic period 

250ms 


sufficient to guarantee the required handoff precision) directed 
towards the requested static node(s). To limit the possible 
interference caused by the transmissions, the mechanism is 
activated only when needed and for the minimum time interval 
required to collect the necessary RSSI samples. 

The handoff mechanism has been implemented in our 
testbed as a dedicated Click kernel element integrated into 
the existing architecture. The module’s functionality include 
handling the probing traffic, collecting and updating the chan¬ 
nel statistics and running the triggering algorithm, as well as 
enforcing the handoff decisions at the networking layer. 

V. Performance evaluation 

In this section we present the results obtained from the 
evaluation of the proposed system. We repeated the same 
experiments illustrated in the preliminary analysis with the 
handoff mechanism activated on the mobile node. The setup 
of the experiments is the same illustrated in Table [IV] and 
the parameters for the handoff algorithm are summarized in 
Table |V 1 

Figure [7] illustrates the obtained results in detail. The raw 
values of the actual RSSI experimented by the traffic over 
a period of 40 seconds are shown in addition to the filtered 
curves, both for the current and the next nodes. The RSSI 
measurements relative to further nodes along the path are not 
shown since they are not significant for the decisional process 
performed on the mobile node. 

As can be seen, when the RSSI of the current node degrades 
noticeably, the handoff is triggered at the precise moment 
indicated by a vertical line. It is easy to verify that the handoff 
is activated almost immediately after that the difference be¬ 
tween the two RSSI curves becomes greater than \q, since the 
comparison takes place in the ’’good” region where the signal 
is above the threshold / 3 . Once again, the results demonstrate 
the effectiveness of the exponential average filter in removing 
the spurious local oscillations of the RSSI samples. Besides, 
looking at the interval between t=160 and t=170, we can see 
that despite the relevant drop in the current node’s RSSI level, 
the triggering mechanism is correctly prevented from firing. 

Finally we evaluated the cumulative delay introduced by 
the handoff process. The average value measured across the 
different tests performed was in the order of 20 ms , which 
allows for sustained speed of the mobile node. 

VI. Conclusions 
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Fig. 7. Handoff triggering. 

proposal is optimized for this specific case, the goal is to 
minimize the additional delay. 

A set of preliminary experiments has been run to gather 
information about channel quality when mobility is involved. 
The results have been used to design an efficient triggering 
algorithm for the handoff. The performance evaluation of our 
design demonstrates that the handoff delay is minimized. In 
addition, the triggering algorithm works well and in particular 
it helps to switch from one AP to another at the right moment. 
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In this paper we have presented an handoff mechanism for 
mass transit networks using IEEE 802.11. The design of our 















